Skip to main content
Version: 2.0

Adjusting Strategies

For two decades I’ve led engineering teams, from scrappy startups to established tech giants. And I’ve seen the same pattern repeat itself time and again: teams clinging to a plan, even when reality screams for a change. We tell ourselves we need to stay the course, to demonstrate discipline and commitment. But in the fast-moving world of software development, "staying the course" is often the quickest path to failure. This isn’t about abandoning principles; it’s about embracing agile adjustment – a willingness to reassess, recalibrate, and redirect when necessary.

The Illusion of Predictability​

The root of this problem lies in our desire for predictability. We crave a clear roadmap, believing that a well-defined plan will shield us from uncertainty. We pour effort into detailed specifications, timelines, and resource allocation, hoping to control the unpredictable nature of building software.

However, software development is inherently unpredictable. User needs shift, technology evolves, and unforeseen technical challenges inevitably emerge. A plan meticulously crafted today may be obsolete tomorrow. This isn't a criticism of planning; it's an acknowledgement of reality. The mistake isn't that we plan, but how we react when the plan inevitably deviates from reality.

I once led a team building a new mobile app. We’d spent weeks detailing every feature, designing wireframes, and estimating timelines. We were confident. Then, within the first two weeks of development, a competitor launched a similar app with a significantly better user experience. Specifically, their app offered a more intuitive onboarding process and a key feature we hadn’t prioritized. Our initial plan was immediately undermined. Sticking to it felt… foolish. We needed to adjust, and fast. We quickly pivoted, incorporating elements of their onboarding flow and accelerating development of the missing feature. This adjustment, though difficult, prevented us from launching a product that would have been quickly overshadowed.

Beyond Retrospectives: A System for Continuous Adjustment​

Many teams address this with retrospectives – and that’s good! But retrospectives often feel like post-mortem analyses – valuable learning opportunities that happen after something goes wrong. While crucial for understanding past mistakes, they are inherently reactive. We need to move beyond solely relying on retrospective analysis to create a system for continuous adjustment, woven into the fabric of our daily work.

Here's a framework I’ve found helpful:

  • Early Exploration (The "Timeboxed Spike"): Before committing to a large feature, dedicate a limited amount of time – a "spike" – to explore the feasibility and potential challenges. This isn't about building a prototype; it's about risk mitigation. The input highlights the benefit of introducing developer guidance at the planning stage, and this spike allows that to happen. It's a small investment that can save significant headaches later.
  • Regular Check-ins (The "Weekly Rhythm"): Establish a weekly rhythm for reviewing progress against key metrics. These aren't status update meetings; they’re conversations about what's working, what's not, and what adjustments are needed.
  • Data-Driven Decisions: Base adjustments on data, not gut feelings. Track key metrics like velocity, bug count, user feedback, and market trends. This provides objective evidence for making informed decisions.
  • "Fail Fast, Learn Faster": Encourage experimentation. It’s okay to try things that don't work, as long as you learn from them quickly. This ties into the idea of making incremental advances rather than aiming for huge leaps.
  • Organizational Levels of Control: Not all adjustments need to be made at the same level. A technical adjustment might be handled within a team, while a strategic shift might require alignment across multiple teams or even the entire organization. Comparative research into team and organizational retrospectives is key here.

The Trap of Methodology​

Often, the rigidity comes from an overreliance on a specific methodology. We become so focused on following the process that we lose sight of the purpose. Methodologies like Agile and Scrum are tools, not dogma. They should empower us to adapt, not constrain us. If a technique isn’t working, someone needs to be empowered to say so. And it shouldn't be framed as a failure, but as a learning opportunity. It takes courage to admit a plan needs adjusting, and leaders must foster a safe environment where these conversations can happen openly.

Aligning with Investors and Staying Lean​

The need for adjustment extends beyond technical execution. It’s crucial to be transparent with stakeholders, especially investors. Understanding and communicating how your strategy aligns with their expectations is vital. If you need to pivot, explain why and how it ultimately benefits the long-term vision.

Staying lean and flexible is paramount. Don't overcommit to a plan that can't adapt to changing circumstances. Embrace experimentation, prioritize learning, and be willing to make adjustments as needed.

A Shift in Mindset​

Adjusting strategies isn’t a sign of weakness; it’s a sign of strength. It demonstrates intellectual honesty, adaptability, and a commitment to delivering value. It requires a shift in mindset – from rigidly adhering to a plan to embracing continuous learning and improvement.

It's not about abandoning our goals; it’s about finding the most effective path to our goals. And in the ever-changing world of software, that path is rarely a straight line.

Take Action: Start by implementing the "timeboxed spike" technique for your next feature planning session. Encourage your team to openly discuss potential adjustments during your weekly check-ins. Adaptability isn't just a useful skill; it's essential for success in modern software development.